Many modern electronic devices enable updating of memory content such as software applications and configuration information. In the event of a power failure or some other type of interruption during an update process, memory contents might be only partially updated. A partial update may result in an inoperable software application or incomplete configuration information, for example, which may in turn render an electronic device or at least some of its functions inoperable. For this reason, so-called boot software code, and possibly other information required to support basic device operation, is usually stored in a memory device that provides persistent storage, such as a Programmable Read Only Memory (PROM).
Although such memory devices preclude subsequent updating of memory contents by writing information to the memory, boot software code stored in a PROM is not lost when a device is powered down. When power is again applied to the device, the boot software code loads a software application into Random Access Memory (RAM), for example, and a processor in the device executes the software application, bringing the device into normal operation. This type of startup sequence is typical of such devices as circuit cards in telecommunication switches, in which relatively few software applications define the functionality of the device. To some extent, this sequence is also common to other types of devices, including computer systems, in which boot software code is executed upon device power up or reset.
The use of a read-only store for boot software code and possibly other information thereby effectively eliminates the possibility of an incomplete update of such information, which may result in a “dead” device. Even though the hardware of such a device may remain intact, a dead device is unable to execute recovery operations or even core startup operations if boot software code, for instance, is incomplete.
One disadvantage associated with such read-only storage, however, is that updating of memory contents is inconvenient. For example, if a new software application requires an update of boot software code, then a new physical memory device programmed with the updated boot software code must be installed in a device before the new software application can be executed. This equipment maintenance scheme becomes particularly time consuming and costly when many devices must be updated, as in the case of circuit cards or other common and widely deployed equipment.
An alternative update technique is typically used for software applications on electronic devices. Often, two banks of FLASH Electrically Erasable PROM (EEPROM) are provided for storing software applications, and each bank stores an entire copy of the same software application. However, the software application in only one of the banks, referred to as the active bank, is executed at a given time. The other bank is generally referred to as the inactive bank. In accordance with normal application update procedures, the software application is updated first in the inactive bank, and responsive to the update being successful, execution is switched over to that bank before the software application in the other bank is updated. This approach allows a software application to be updated with minimal risk of affecting the operation of the device. If an update operation is interrupted before completion, the software application remains in the active bank.
Implementation of this type of redundancy model for boot software code would require additional hardware, specifically a second memory device for boot software code, since only a single boot PROM is normally provided in an electronic device. A second memory device not only adds cost, but also increases power consumption, heat generation, and physical space requirements, and may therefore not be feasible in some types of device.
Another possible option to facilitate boot software code updating is to store boot software code in an erasable and programmable memory device such as an EEPROM. After a device has executed boot software code and is operational, additional functionality supported on the device could then erase the EEPROM and reload new boot software code into the EEPROM. However, if a power outage, card pull in the case of a circuit card, load corruption, or other such event occurs during reloading of boot software code, then the reload fails and the device is no longer able to start up from its boot EEPROM.